Conventional distributed directory environments having homogeneous, standalone LDAP (Lightweight Directory Access Protocol) servers (Server1, Server2 . . . ), as illustrated in FIG. 2, have different LDAP subtrees, while each server preferably has its own database (DB). LDAP clients (Client1, Client2) communicate to these servers through LDAP proxy servers (Proxy1, Proxy2). Depending oil the client request, a proxy server selects an appropriate LDAP server to route the request. LDAP server processes any requests made and sends a reply back to the client through the LDAP proxy. Multiple proxy servers can be configured to achieve failover and load balancing in the proxy servers. However, disadvantages have arisen through such an arrangement.
Since most of the LDAP servers arc stand-alone, replication needs to be setup in order to ensure a high availability of data; thus, in the event of failure of any LDAP server, all requests intended for the failed LDAP server can be routed to a replica (replicated) server. However, if the load on a LDAP server is relatively high, then the load cannot be distributed elsewhere since each LDAP server will be tightly coupled with its own database.
On the other hand, adding more LDAP servers can cause disadvantages relating to complexity of the network. Particularly, if more LDAP servers are added in the distributed directory, then in order for a proxy to be aware of the new servers added to the network, additional configurations needs to be undertaken in the proxy and it may be necessary at this time for the proxy to be restarted. For distributing client load amongst the proxy servers, if new proxy servers are added, they need a great deal of configuration to be undertaken every time that proxy servers are added increasing operational, computational, resource and other costs, and causing immense waste of resources.